ChatGPT/DALL E are some of the latest technology words used in the last few months and I was curious to explore the new technology. So went to https://openai.com/ and signed up for an account to get started with it. Once you sign up you can have a free research analysis with the ChatGPT which is basically like a chat bot but works with AI models which keeps learning and providing outputs based on the model learning. The previous version InstructGPT was basic and didn’t have much safety features added but ChatGPT is quite sensitive to the queries posted which was pretty impressive at the first check. You can check the difference between both in the examples provided in the site.
As Product Manager I would spend time on PRD documents with iterations after iterations and most of the time would spent in making sure the designs proposed esp with Data Models and API Designs are with the standard formats. So, wanted to validate if ChatGPT could come up with a basic PRD and this is what the result was:
User: create a PRD for a health monitoring API which gets data from the heart beat device and shows vital information
ChatGPT:
Product Requirement Document
Title: Health Monitoring API
Overview:
The Health Monitoring API is a RESTful API that allows clients to retrieve data from a heart rate monitoring device and display vital information. It is intended to be used by health care providers, wellness apps, and other organizations that need to access and manage health data.
Functional Requirements:
- The API should allow clients to retrieve real-time data from the heart rate monitoring device.
- The API should allow clients to retrieve historical data for a specified time period.
- The API should provide data points such as heart rate, activity levels, and sleep patterns.
- The API should return data in JSON format.
Non-Functional Requirements:
- The API should have a rate limit of no more than 1000 requests per hour per client.
- The API should have a response time of no more than 500ms for 95% of requests.
- The API should have a maximum uptime of 99.9%.
- The API should be secured using OAuth2.
API Endpoints:
GET /vitals/realtime: Retrieves real-time data from the heart rate monitoring device.GET /vitals?start={start_timestamp}&end={end_timestamp}: Retrieves historical data for a specified time period.
Data Model:
- Vital Sign:
- Timestamp (datetime)
- Heart Rate (integer)
- Activity Level (string)
- Sleep Pattern (string)
Pretty Impressive I would say at least with the basic information I provided. Obviously the use cases which are quite important for a PRD was missing which needs Human intervention but the API design, structure and model was pretty spot on. I’m going to play around and see if the model can be enhanced if I give more specific requirements and how the model is going to be trained for that.
The fun part continues, I asked ChatGPT to create a yaml for the above API and this was the result.
Here are the YAML definitions for the Health Monitoring API based on the design provided:
openapi: 3.0.0
info:
title: Health Monitoring API
version: 1.0.0
servers:
- url: https://api.healthmonitor.com
paths:
/vitals/realtime:
get:
summary: Retrieves real-time data from the heart rate monitoring device.
responses:
'200':
description: Real-time data successfully retrieved.
content:
application/json:
schema:
$ref: '#/components/schemas/VitalSign'
/vitals:
get:
summary: Retrieves historical data for a specified time period.
parameters:
- name: start
in: query
description: Start timestamp for the time period (inclusive).
required: true
schema:
type: string
format: date-time
- name: end
in: query
description: End timestamp for the time period (exclusive).
required: true
schema:
type: string
format: date-time
responses:
'200':
description: Historical data successfully retrieved.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/VitalSign'
components:
schemas:
VitalSign:
type: object
properties:
timestamp:
type: string
format: date-time
description: Timestamp of the vital sign data point.
heartRate:
type: integer
description: Heart rate in beats per minute.
activityLevel:
type: string
description: Level of activity, such as 'sedentary' or 'active'.
sleepPattern:
type: string
description: Sleep pattern, such as 'deep' or 'light'.
Next step I asked it to create the code in Java
Here is an example of how the Health Monitoring API could be implemented in Java using the Spring framework:
Copy code@RestController @RequestMapping("/vitals") public class HealthController { @Autowired private HeartRateMonitorService heartRateMonitorService;@GetMapping("/realtime") public ResponseEntity<VitalSign> getRealTimeVitals() { VitalSign vitalSign = heartRateMonitorService.getRealTimeVitals(); returnResponseEntity.ok(vitalSign); } @GetMapping publicResponseEntity<List<VitalSign>> getHistoricalVitals(@RequestParam("start") String start,@RequestParam("end") String end) { Date startDate = parseDate(start);Date endDate = parseDate(end); List<VitalSign> vitalSigns = heartRateMonitorService.getHistoricalVitals(startDate, endDate); returnResponseEntity.ok(vitalSigns); } private Date parseDate(String dateString) { try { return new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'").parse(dateString); } catch (ParseException e) { thrownew InvalidRequestException("Invalid date format: " + dateString); } } }
Note: This is just a basic example of how the API could be implemented, and does not include all the features and functionality described in the Product Requirement Document. For instance, the example does not include rate limiting, security, or error handling.
I liked how it had a disclaimer on where the examples are not included.
Next step is the Unit test cases:
Here is an example of how unit tests could be written for the Health Monitoring API in Java using the JUnit framework:
Copy code@SpringBootTest @AutoConfigureMockMvc public class HealthControllerTest {@Autowired private MockMvc mockMvc; @MockBean private HeartRateMonitorService heartRateMonitorService; @Test public void testGetRealTimeVitals() throws Exception { VitalSign vitalSign = newVitalSign(Instant.now(), 72, "active", "deep");when(heartRateMonitorService.getRealTimeVitals()).thenReturn(vitalSign); mockMvc.perform(get("/vitals/realtime")) .andExpect(status().isOk()) .andExpect(jsonPath("$.timestamp").value(vitalSign.getTimestamp().toString())) .andExpect(jsonPath("$.heartRate").value(vitalSign.getHeartRate())) .andExpect(jsonPath("$.activityLevel").value(vitalSign.getActivityLevel())) .andExpect(jsonPath("$.sleepPattern").value(vitalSign.getSleepPattern())); } @Test public void testGetHistoricalVitals() throws Exception {List<VitalSign> vitalSigns = Arrays.asList( new VitalSign(Instant.parse("2020-01-01T00:00:00Z"), 72, "active", "deep"), new VitalSign(Instant.parse("2020-01-01T12:00:00Z"), 74, "sedentary", "light") );when(heartRateMonitorService.getHistoricalVitals(any(Date.class), any(Date.class))) .thenReturn(vitalSigns); mockMvc.perform(get("/vitals?start=2020-01-01T00:00:00Z&end=2020-01-02T00:00:00Z")) .andExpect(status().isOk()) .andExpect(jsonPath("$", hasSize(2))) .andExpect(jsonPath("$[0].timestamp").value(vitalSigns.get(0).getTimestamp().toString())) .andExpect(jsonPath("$[0].heartRate").value(vitalSigns.get(0).getHeartRate())) .andExpect(jsonPath("$[0].activityLevel").value(vitalSigns.get(0).getActivityLevel())) .andExpect(jsonPath("$[0].sleepPattern").value(vitalSigns.get(0).getSleepPattern())) .andExpect(jsonPath("$[1].timestamp").value(vitalSigns.get(1).getTimestamp().toString())) .andExpect(jsonPath("$[1].heartRate").value(vitalSigns.get(1).getHeartRate())) .andExpect(jsonPath("$[1].activityLevel").value(vitalSigns.get(1).getActivityLevel())) .andExpect(jsonPath("$[1].sleepPattern").value(vitalSigns.get(1).getSleepPattern()
This was definitely fun to play around with. Many people have concerns if this will replace humans, I would strongly say no. This needs a lot of human intervention to create specific human tasks but has lot of potential in multiple functionalities for each job role and for various industries. Many new applications can built on top of this powerful tool/API. I’m yet to check the DALL E and see how image processing is being used. This can definitely optimise the way you work. I’m going to play around and see how it gets trained more.
Chennaivaasi 